REMARKS 

The Office Action dated August 10, 2007, has been received and carefully noted. 
The above amendments to the claims and the following remarks, are submitted as a full 
and complete response thereto. 

Claims 1-42 are pending. Claims 1, 21, 22, 31, and 42 are herein amended 
without adding new matter. Applicants respectfully request reconsideration in view of 
the following and submit claims 1-42 for reconsideration. 

Applicants appreciatively acknowledge Examiner's participation in a telephone 
interview held on October 24, 2007. As discussed in the interview, the foregoing 
amendments and the following remarks address the rejections cited in the Office Action. 

Rejection under 35 U.S.C. §103(a) based on Kristol and Mai kin 

Claims 1-14 and 21-42 were rejected under 35 U.S.C. §103(a) as being allegedly 
unpatenttable over Kristol et al. (US 5,541,927) in view of Malkin et al. (US 6,311,206). 
As discussed in the examiner interview, Applicants respectfully traverse this rejection for 
at least the following reasons. 

As amended, claim 1, upon which claim 2-20 depend, is generally directed toward 
a network hub in a communication network that includes a server. The server detects 
status information from the communication network and pushes the status information to 
a client without a request for the status information from the client. The status 
information includes information about the communication network. 

- 11 - 



As amended, claim 21, upon which claims 22-30 depend, is generally directed 
toward a communication apparatus that includes a network information detector that 
detects network information from a communication network and a network information 
table that stores network information detected by the network information detector. The 
communication apparatus also includes a network information transmitter that selectively 
pushes the network information in the network information table without a request for the 
network information. The network information includes information about the 
communication network to which the communication apparatus corresponds. 

As amended, claim 31, upon which claims 32-41 depend, is generally directed 
toward a communication apparatus that includes a network information receiver that is 
operably connected to a communication network. The communication apparatus also 
includes a network information table that stores network information from the network 
information receiver. The communication apparatus also includes a network operations 
detector that detects networking information from the communication network and 
produces operational information of an operational state of the network. The 
communication apparatus also includes a network information transmitter that transmits 
the operational information of an operational state of the network without a request for 
the operational information. The network information includes information about the 
communication network. 

As amended, claim 42 is generally directed toward a status apparatus for use in a 
communication network. The status apparatus includes a network hub in a 
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communication network and a server in communication with the network hub. The 
server detects status information from the communication network and pushes the status 
information to a client without a request for the status information from the client. The 
status information includes network information about the communication network. 

It is respectfully submitted that the combination of Kristol and Malkin fails to 
disclose or suggest all the elements of claims 1, 21, 31, and 42. 

Kristol is generally directed to a method for multicasting using transport layer 
protocols that are suitable for ATM networks. In Kristol, a source multicasts data packets 
to all destinations. In turn, each destination that is first in a column sends its status to the 
source, and the remaining destinations in the column send their status to the first 
destination in the column. The first destination in the column then locally re-multicasts if 
any destinations below the first destination in the column did not receive the multicast 
packet. The source re-multicasts if a first destination in a column has not received the 
packet. In this manner, Kristol discloses a method of network multicasting. 

However, Kristol does not disclose or suggest a ''server configured to detect 
status information from the communication network and push the status information 
to a client... wherein the status information... comprises information about the 
communication network" as recited in claim 1. [emphasis added]. Instead, in Kristol, the 
source multicasts packets to all destinations, receives a notification if certain destination 
did not receive all the packets, and then re-multicasts the packets. Though Kristol 
discloses the destinations as sending packets to the source regarding which blocks have 

-13- 



been received, this data flow is in the exactly opposite direction from that disclosed in 
claim 1, where "the server [is] configured to. . .push status information to a client. 

When the Kristol source receives a notification that only some of the packets were 
received, the source does not send that notification back to the destination; instead, the 
source re-multicasts the original packets. Adapting Kristol to push the block information 
back to the destinations would be the exact opposite of what Kritosl discloses. 
Accordingly, Kristol does not disclose a "server configured to detect status information 
from the communication network and push the status information to a client... wherein 
the status information... comprises information about the communication network" as 
recited in claim 1. [emphasis added]. 

Furthermore, Applicants respectfully assert that Kristol fails to disclose "the server 
configured to detect status information from the communication network and push the 
status information to a client... wherein the status information... comprises information 
about the communication network." [emphasis added]. Though the Kristol source may 
be able to acknowledge a transmission from a destination regarding missing blocks, this 
is not to say that the Kristol source is capable of detecting status information about the 
communication network. Information about a network includes information distinct from 
whether or not a particular packet was received by a destination. It follows that enabling 
the detection of status information about the communication network would involve 
logical instructions and/or circuitry beyond that required to merely acknowledge a 
packet-missing notification. Accordingly, Applicants respectfully assert that Kristol fails 
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to disclose or suggest, "the server configured to detect status information from the 
communication network and push the status information to a client... wherein the status 
information... comprises information about the communication network" [emphasis 
added]. 

Additionally, Malkin fails to remedy the deficiencies of Kristol. More 
specifically, Malkin fails to disclose or suggest, at least, "the server configured to detect 
status information from the communication network and push the status information to a 
client... wherein the status information... comprises information about the communication 
network." 

Malkin is generally directed toward a method for providing awareness-triggered 
pushes. In Malkin, a source server requests an awareness server to notify it when a 
specific client entity is in a particular state. When the awareness server learns that the 
client has entered such a state, the awareness server notifies the source server (or 
sometimes a push proxy server) accordingly. Sometimes, the awareness server will 
communicate certain information to the source server during the notification. This may 
include connectivity status information, PING information, information regarding an 
automated notification from the client, and so on. In response to the notification, the 
source server (or push proxy server) sends "data" to the client. 

However, Malkin fails to disclose or suggest "the server configured to detect 
status information from the communication network and push the status information to 
a client... wherein the status information... comprises information about the 
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communication network." [emphasis added]. Rather, Malkin discloses that the source 
server receives a message about a target client in a response to a request for information 
about the target client. Receiving a purposefully transmitted message is not comparable 
to having to "detect status information." The logical instructions and circuitry required to 
"detect" a particular type of information in a flow of data is clearly distinct from that 
required to merely receive a purposefully transmitted message in response to a 
purposefully transmitted request. Therefore, Applicants respectfully assert that Malkin 
fails to disclose or suggest "the server configured to detect status information from the 
communication network and push the status information to a client... wherein the status 
information... comprises information about the communication network." [emphasis 
added]. 

Additionally, Malkin fails to disclose or suggest a "the server configured to detect 
status information from the communication network and push the status information to 
a client... wherein the status information... comprises information about the 
communication network." [emphasis added]. Instead, Malkin discloses that the 
awareness server, when notifying the source server of the particular status of a particular 
client, may communicate certain "critical data" such as connectivity status information, 
PING information, a information regarding an automated notification from the client, and 
so on. However, there is no disclosure or suggestion in Malkin that this information is 
then pushed to the client. Instead, Malkin distinctly and generically discloses that the 
sources server only communicates "data" to the client. Malkin is silent regarding 
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communicating status information to the client. The fact that Malkin is silent in this 
regard should be of no surprise because the information sent to the source server as part 
of the notification is likely already owned by, or readily accessible to, the client. 
Accordingly, Applicants respectfully assert that Malkin fails to disclose or suggest, at 
least, "the server configured to detect status information from the communication 
network and push the status information to a client... wherein the status 
information... comprises information about the communication network." [emphasis 
added]. 

Furthermore, Applicants respectfully assert that any attempt to combine the 
Malkin source server, network, and awareness server would be an improper analysis 
based on hindsight. Malkin is explicitly directed toward a highly distributed network as 
disclose in Figures 1, 2, and 5, and again in Figure 7. Indeed, Malkin not only fails to 
disclose or suggest the server of claim 1, but teaches away from such a server by 
repeatedly and explicitly disclosing such a highly distributed network. Applicants 
respectfully assert that cramming the distributed functionality attributed to multiple 
servers and a network into a single hub or switch is not a fair interpretation of Malkin. 

For all of the foregoing reasons, Applicants respectfully assert that Kristol and 
Malkin fail to disclose or suggest, at least, "the server configured to detect status 
information from the communication network and push the status information to a client 
without a request for the status information from the client... wherein the status 



- 17- 



information... comprises information about the communication network" as recited in 
claim 1. 

Accordingly, Applicants respectfully request that the § 103(a) rejection of claim 1 
be withdrawn. Similarly, Applicants request that the § 103(a) rejection of independent 
claims 21, 31, and 42 be withdrawn on similar grounds since they contain similar 
limitations, though each claim has its own scope. Also, Applicants request that the 
103(a) rejection of dependent claim 2-14, 22-30, and 32-41 be withdrawn for at least their 
dependence on claims 1,21, and 31. 

Rejection under 35 U.S.C. 8103(a) based on KristoK Malkin, and Fuiino 

Claims 15-20 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Kristol in view of Malkin, and further in view of Fujin et al. (US 5,651,006). However, 
Applicants traverse this rejection for at least the following reasons. 

As presented above, Kristol and Malkin fail to disclose or suggest, at least, "the 
server configured to detect status information and push status information to a client 
without a request for the status information from the client... wherein the status 
information... comprises information about the communication network" as recited in 
claim 1, upon which claims 15-20 depend. Fujin does not remedy the deficiencies of 
Kristol and Malkin. 

Fujin generally discloses a hierarchical communication network management 
system that includes a plurality of agents and sub-managers connected to lower 
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communication networks and an integration manager connected to a higher 
communication network. The Fujin sub-managers function as agents to the integration 
manager and as managers to the agents. This enables the user of Simple Network 
management Protocol (SNMP) between each agent and its sub-manager and between a 
sub-manager and the integration manager. This also enables the transmission of 
management information between an integration manager and sub-managers based on a 
small volume of management packets. 

However, Fujin fails to disclose "the server configured to detect status 
information from the communication network and push the status information to a 
client without a request for the status information from the client... wherein the status 
information... comprises information about the communication network" as recited in 
claim 1. [emphasis added]. Instead, Fujin discloses that the sub-managers function as 
agents to the integration manager and as managers to the agents to enable the use of 
SNMP. Though this intermediary functionality of the sub-managers is useful within the 
scope of Fujin itself, it is certainly not comparable to the claim 1 server that detects and 
pushes network status information. 

Additionally, Fujin does not disclose "the server configured to detect status 
information and push status information to a client without a request for the status 
information from the client... wherein the status information... comprises information 
about the communication network" as recited in claim 1. [emphasis added]. In Fujin, a 
sub-manager operates as an intermediary between an integration manager and agents, as 
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described above. However, Fujin is void of any reference of a sub-manager pushing data 
to a client, let alone any references of detecting network data and pushing the network 
data to the client without a request there from. 

Furthermore, Fujin fails to disclose "the server configured to detect status 
information and push status information to a client without a request for the status 
information from the client... wherein the status information. ..comprises information 
about the communication network" as recited in claim 1. [emphasis added]. Though 
Fujin discloses the transmission of management information, there is no disclosure or 
suggestion that this management data is comparable to the "status information" of claim 
1 . Fujin discloses management information as information held in a format called MIB 
(Management Information Base) which is a set of management objects expressed in a tree 
structure. Clearly, this management information is not comparable to the status 
information of claim 1 . 

For all of the foregoing reasons, Applicants respectfully assert that Kristol, 
Malkin, and Fujin fail to disclose or suggest each limitation of claim 1. Accordingly, 
Applicants respectfully request that the § 103(a) rejection of claims 15-20 be hereby 
withdrawn for at least their dependency from claim 1. 
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Conclusion 



In light of the foregoing, Applicants respectfully request that the rejection 
presented in the Office Action be withdrawn. It is also respectfully requested that the 
application pass to issue with the allowance of claims 1-42. If for any reason the 
Examiner determines that the application is not now in condition for allowance, it is 
respectfully requested that the Examiner contact, by telephone, the Applicants' 
undersigned representative at the indicated telephone number to arrange for an interview 
to expedite the disposition of this application. 

In the event this paper is not being timely filed, the applicants respectfully petition 
for an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 
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AMENDMENTS TO THE DRAWINGS : 

The attached Replacement Drawing sheets including formal drawings for 
Figs. 1-7, and submitted herewith to replace the original drawing sheets filed on May 26, 
2000. No new matter has been added. 
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